Secure digital identity has emerged as the most frequent and vital ‘traveler’ along the enterprise technology thoroughfare that connects more users to more networks on more devices in more places than ever thought possible. Given this robust computing roadway along which all digital identities must journey, the need for fortified and agile identification management systems is paramount. These necessary identification management systems must work tirelessly to mitigate security breaches, avoid slowing down essential network and cloud functionality, and prevent the occurrence of system failure and user error. However, these daunting missions are all the more complicated by the sheer volume of cross-network tasks executed by an enterprise's sphere of users every day. For example, that sphere may include the digital identities of employees, contractors, clients, customers, vendors, suppliers, trading partners, sister company employees, acquisition and merger parties, investors, and any other affiliate entity. All of these digital identities must then be authenticated to be allowed access to a countless variety of databases, content repositories, proprietary files, software as a service (SaaS) sites, intranets, and third-party industry hubs, to note a few.
These fragmented and sprawling webs of digital identities may be coordinated, integrated, and controlled by an identity management system that involves identity federation. Identity federation describes the technical architecture and unique portability of a user's digital identity across independent security domains and autonomous networks. The primary function of identity federation is the allowance of a user of one security domain and/or autonomous network to seamlessly and securely engage another security domain and/or autonomous network without user-administrative encumbrances and redundancy. In this federated construct, an identity provider (e.g., Active Directory®) asserts authentication protocols and houses identity information related to an enterprise's users. When a user tries to complete a particular task that engages one of the enterprise's one or more service providers, that service provider will receive a particular set of identity information from the identity provider as it relates to the user in question. The service provider will then check and consume the data to confirm both authorization of the user and availability of the user's intended application. Collectively, this enables the portability and interoperability of identity information across otherwise tenuous boundaries of security domains.
Though nimble in design, there may be notable shortcomings of current federated identity architecture, primarily in the inability of a user identity that is defined in an enterprise identity provider to be used in more than one sovereign cloud services network (i.e., national or regional cloud services network). For example, an enterprise with users that utilize cloud services in one cloud services network may want its users to access services offered in another cloud services network. In doing so, this enterprise may also seek to use the same user identity defined in its on-premise enterprise identity provider for its users. However, enterprises wanting to access another sovereign cloud services network with the same set of on-premise user identity information (e.g., username and password) must first complete a cloud tenant setup with the other sovereign cloud in question, whereby its unique domain name is registered and validated. With this is mind, current cloud-based identity providers (e.g., Azure® Active Directory®) may not accept the same domain name that is already registered with another cloud-based identity provider in another cloud services network. This makes using the same user identification information near impossible.